A “workflow” is a familiar concept to many people. Generally, a “workflow” is any series of steps or activities necessary for completing a particular task. A “workflow process” is any set of related activities that the workflow application treats as a single unit of activity. For example, the process of obtaining permanent resident status (a “green card”) for an alien employee could be described as a workflow. To obtain a green card, someone must file a labor certification with the Department of Labor. The Department of Labor then must process the certification, first at the state level and then at the national level. If the Department of Labor approves the certification, someone must file a second application with the Immigration and Naturalization Service (INS), which then investigates and approves or rejects the application. Of course, each of the filing and processing activities are themselves comprised of smaller tasks and activities, but in this example, each of the filing and processing activities probably would be treated as a workflow process.
A “workflow application” is any computer program designed to coordinate or manage a workflow, particularly in an enterprise setting. Thus, in the above example, a workflow application could coordinate the workflow processes (the filing and processing activities) among the filer, the Department of Labor, and the INS.
Workflow applications are common. Many workflow applications are highly specialized for a specific industry, such as the medical application disclosed in U.S. Pat. No. 6,697,783 (issued Feb. 24, 2004). Other such systems, though, have been designed to accommodate more generalized needs, including the system disclosed in U.S. Pat. No. 6,567,783 (issued May 20, 2003).
Decision support systems also are common in the enterprise world. In general, a decision support system is any means for gathering information from one or more sources, analyzing the information, and predicting the impact of a decision before it is made. A decision support system frequently is implemented as a computer program, and just as frequently is integrated with other types of programs to create a more comprehensive application. U.S. Pat. No. 6,697,783, U.S. Pat. No. 6,567,783, U.S. Patent App. No. 2003/0195762 (published Oct. 16, 2003), and WO 2002/29682 (published Apr. 11, 2004), for example, all disclose a workflow application with some form of integrated decision support system.
Tools for developing workflow applications and decision support systems probably are as common as the applications themselves. Again, though, many of these tools are specialized for a specific industry or type of application. WO 2002/29682, for example, discloses a tool for developing an automated loan processing system to meet the needs of an individual enterprise. Other tools, though, have attempted to generalize the development process, such as the tools described in U.S. Pat. No. 6,567,783 and U.S. Patent App. No. 2003/0195762.
Thus, neither the concept of a “workflow” nor a “decision support system” is new. Nor is the use of a computer to implement a workflow process or a decision support system new. The structure and organization of such implementations, however, have seen rapid change in recent years. In particular, advances in network architectures have changed application development significantly.
Like all computer programs, workflow applications and decision support systems may be stand-alone programs or part of a tiered-architecture. In general, a tiered-architecture includes multiple tiers (or “layers”) of software that provide a different layer of service at varying levels of detail to the tiers above and beneath them. For years, many applications were designed to run in a two-tier architecture, referred to commonly as a “client-server architecture.” The functionality of such an application generally was divided between a “client” program and a “server” program. The client program generally provided a user interface and implemented most of the application's logic (commonly referred to in an enterprise context as “business logic”). The server program, on the other hand, provided centralized access to data, so that multiple clients could access the data through a single server. In recent years, though, this traditional two-tier client/server system has been displaced slowly by more sophisticated multi-tier systems. In general, a multi-tier system places at least one intermediate component between the client and the server. These components are referred to commonly as “middleware.” Today, programmers often implement an application's logic in middleware programs, rather than in a traditional client program.
Tools for developing workflow applications and decision support systems generally have been designed for traditional, two-tier client-server architectures, or even for monolithic (single-tier) architectures. Tools for developing multi-tier workflow applications are far less common, and existing tools do not provide an effective means for integrating a decision support system into a workflow application. The invention described in detail below addresses the need in the art for such a means.
This and other objects of the invention will be apparent to those skilled in the art from the following detailed description of a preferred embodiment of the invention.